Hybrid shadow paging for storing a database

ABSTRACT

A computer-implemented method for storing a database state. The method comprises providing a database, receiving by the database one or more write events, logging each write event, each logged write event thus forming a new state on the database, buffering pages modified or created by the write events, and creating a patch by flushing to a database storage the buffered pages if a threshold has been met.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority under 35 U.S.C. § 119 or 365 toEuropean Application No. 20306643.6, filed Dec. 21, 2020. The entirecontents of the above application are incorporated herein by reference.

FIELD

The disclosure relates to the field of computer programs and systems,and more specifically to a method, system and program for a hybridshadow paging for storing a database.

BACKGROUND

A number of systems and programs are offered on the market for thedesign, the engineering and the manufacturing of objects. CAD is anacronym for Computer-Aided Design, e.g. it relates to software solutionsfor designing an object. CAE is an acronym for Computer-AidedEngineering, e.g., it relates to software solutions for simulating thephysical behaviour of a future product. CAM is an acronym forComputer-Aided Manufacturing, e.g., it relates to software solutions fordefining manufacturing processes and operations. In such computer-aideddesign systems, the graphical user interface plays an important role asregards the efficiency of the technique. These techniques may beembedded within Product Lifecycle Management (PLM) systems. PLM refersto a business strategy that helps companies to share product data, applycommon processes, and leverage corporate knowledge for the developmentof products from conception to the end of their life, across the conceptof extended enterprise. The PLM solutions provided by Dassault Systèmes(under the trademarks CATIA, ENOVIA and DELMIA) provide an EngineeringHub, which organizes product engineering knowledge, a Manufacturing Hub,which manages manufacturing engineering knowledge, and an Enterprise Hubwhich enables enterprise integrations and connections into both theEngineering and Manufacturing Hubs. All together the system delivers anopen object model linking products, processes, resources to enabledynamic, knowledge-based product creation and decision support thatdrives optimized product definition, manufacturing preparation,production and service.

These applications are examples of “creative authoring applications”that provide the users with the capability of working in isolation fromeach other, exploring different solutions, and using an incrementalmethod to solve problems by accessing different states of their work andnavigating the history of modifications in a “time travel” way. By “timetravel” we mean accessing past states to of the database efficiently(that is to say, with a controlled elapse time deemed constant for allstates) and be able to run read-only queries on these states. Storingthe history of modifications and accessing past states of the databasein a time travel way can also be important in certification processessuch as the one existing in aeronautics to audit and understand in theircontext modifications made in the past.

Such creative authoring applications comprise long transactions incontrast to short transactions. Long transaction that are also referredto as long-running transactions are computer database transactions thatavoid locks on non-local resources, use compensation to handle failures,and typically use a coordinator to complete or abort the transaction.The compensation restores the original state, or an equivalent. Hence,and in particular when the database is concurrently accessed by multipleusers, transactions are required to respect the so-called ACIDproperties, namely, Atomicity, Consistency, Isolation and Durability, toguarantee the accuracy and integrity of the data stored in the databaseeven in the event of errors, power failures, etc. In the context ofdatabases, a sequence of database operations that satisfies the ACIDproperties (and these can be perceived as a single logical operation onthe data) is called a transaction. For example, a transfer of funds fromone bank account to another, even involving multiple changes such asdebiting one account and crediting another, is a single transaction.

Among ACID properties, the consistency should be defined in relation toapplication-defined semantics and cannot be discussed for a genericdatabase.

In particular, for creative authoring applications, it is desirable toprovide the best performances for a mix workload of read and writetransactions and the transactions should be creatable on any state ofthe database to provide a user activity in an incremental method whichtypically consists of several repetitive attempts by the user to testand verify different scenarios. In addition, to comply with creativeauthoring applications, all states of the database should be accessibleefficiently and with the same cost. In other words, all database statesare considered equals.

Different conventional strategies exist in database systems in order toprovide one or more ACID properties for a database.

The first strategy is shadow paging which was introduced to support longtransactions such as in CAD applications while providing atomicity,consistency and durability of transactions at the file level by using anappend-only storage system. In shadow paging, two versions of files aremaintained, a shadow version and a current version wherein the currentversion of a file is modified and never the shadow version. These shadowversions are used to provide atomicity, consistency and durability.

The drawbacks of shadow paging comprise the amount of used I/O resourcesas it needs to wait for all pages to be written to disk beforecommitting. Moreover, the released database libraries in which shadowpaging has been employed restrict the number of versions to only two,which is by far insufficient for authoring applications; this has beendiscussed in Gray et al., The recovery manager of the System R databasemanager, ACM Computing Surveys (CSUR), 1981, Vol. 13, No. 2, pages223-242, and in Chu, MDB: A memory-mapped database and backend forOpenLDAP, Proceedings of the 3rd International Conference on LDAP,Heidelberg, Germany, 2011, page 35.

The second strategy is the logging strategy via write-ahead logging(WAL) to preserve atomicity and durability. In this technique, changesare first recorded in a log and be written on a non-volatile storage,before being written to the database. An advantage of this strategy isits efficiency regarding I/O costs. However, for long transactions inauthoring systems, keeping the history of modifications as a log impliesan important CPU cost to re-construct a desired database state.

Within this context, there is still a need for an improved method toobtain a database that combines time-travel properties and longtransaction capabilities of authoring systems, while reducing computingresources and memory generated by I/O.

SUMMARY

It is therefore provided a computer-implemented method for storing adatabase state. The method comprises providing a database. The methodfurther comprises receiving by the database one or more write events,logging each write event, each logged write event thus forming a newstate on the database. The method further comprises buffering pagesmodified or created by the write event(s), and creating a patch byflushing to a database storage the buffered pages if a threshold hasbeen met.

The computer-implemented method for storing a database may comprise oneor more of the following:

-   -   the method further comprises        -   repeating the creating each time the threshold has been met            consecutive to receiving by the database new write event(s).            Each repetition of the creating comprises creating a list of            the new pages that are modified or created by the new write            event(s) received by the database, therefore obtaining a            sequence of states wherein some states have respectively a            corresponding patch;    -   each created new patch further comprises a mapping table        comprising a mapping between the physical addresses of the        buffered pages and logical addresses of the pages at a data        structure layer of the database;    -   each logged write event has a local mapping table by duplicating        the existing mapping table in the buffer and applying the local        mapping up to the desired logged write event;    -   the mapping table is based on a lockless compare- and        swap-array.    -   the created patch further comprises a descriptor comprising at        least one of:        -   the number of physical pages modified or created by the new            write event(s);        -   metadata for checking integrity of the descriptor;        -   a timestamp of the new write event(s);    -   in the presence of the descriptor, the logged write event        successfully committed to the memory buffer, otherwise the        logged write event would be discarded;    -   the threshold is a size of the event log and/or a size of the        buffered pages and/or a time of reconstruction from the log        and/or a time that elapsed since the last flush was carried out;    -   the database storage of data pages is append-only;    -   logging each write event comprises writing a history of        modifications as the log of event(s) to the log storage on the        disk for intermediate transactions which are transactions before        flushing to the database storage; and/or    -   the log storage is append-only.

It is further provided a computer-implemented method for accessing adatabase state. The method comprises providing a database having atleast two database states stored according to the method for storing adatabase state. The method for accessing a database state furthercomprises receiving by the database a read event on an identified state,retrieving a patch in the sequence of states from the database storage,retrieving a list of logged write events that occurred between theretrieved patch and the identified state, and applying the list oflogged write events to the retrieved patch, therefore recovering theidentified database state.

The retrieved patch in the computer-implemented method for accessing adatabase state may be the patch that minimizes the length or the size ofthe list of the logged write events occurred between the retrieved patchand the identified database state.

It is further provided a computer program comprising instructions forperforming the method for storing a database state and/or the method foraccessing a database state.

It is further provided a database comprising computer readable storagemedium having recorded thereon the computer program.

The database may comprise a transaction manager that links datastructures with the storage layer's transaction and orchestrate commits,wherein:

-   -   the transaction manager in the data structure layer sends the        event log to the storage layer;    -   the persistence of the event log on the log-storage is        acknowledged by the storage layer; and    -   after being acknowledged, the transaction manager closes the        transaction in the storage layer and sends the modified pages to        a memory buffer.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments will now be described, by way of non-limiting example, andin reference to the accompanying drawings, where:

FIG. 1 shows a flowchart of an example of the method of storing adatabase state;

FIG. 2 shows a flowchart of an example of the method of accessing adatabase state;

FIG. 3 shows a schematic of an example modifying data pages andrecording modified data pages in an append only storage;

FIG. 4 shows an example of the addressing in the mapping table of thepatch and the shared altered state as well as the structure of anexample of a log file;

FIG. 5 shows an example of a commit sequence of the method; and

FIG. 6 shows an example of a system.

DETAILED DESCRIPTION

With reference to the flowchart of FIG. 1, it is proposed acomputer-implemented method for storing a database state. The methodcomprises providing S10 a database.

By “database”, it is meant any collection of data (i.e. information)organized for search and retrieval (e.g. a relational database, e.g.based on a predetermined structured language, e.g. SQL). When stored ona memory, the database allows a rapid search and retrieval by acomputer. Databases are indeed structured to facilitate storage,retrieval, modification, and deletion of data in conjunction with tovarious data-processing operations. The database may consist of a fileor set of files that can be broken down into records, each of whichconsists of one or more fields. Fields are the basic units of datastorage. Fields are also referred to as pages. Database pages are theinternal basic structure to organize the data in the database files. Apage is a basic unit of I/O operation. The size of page will depend onthe implementation of the database; for instance, in SQL database serverthe size of a page is 8 kB.

Users may retrieve data in the database primarily through queries. Usingkeywords and sorting commands, users can rapidly search, rearrange,group, and select the field in many records to retrieve or createreports on particular aggregates of data according to the rules of thedatabase management system being used.

A database state is a set of stored data at a given time. A database isalways in one specific state. Adding, removing or modifying theinformation stored in a database changes its state. For example, adatabase may contain information about different designs of a CAD modelcharacterized by some, for instance length and/or shape, parameters. Theact of modification of any of these parameters, for example during thedesign process, and storing this new set of parameters in the databasewill change its state.

A database can be depicted as a conceptual model that comprises severalabstraction layers or levels, each abstraction layer providing aconceptual model or algorithm that may be away from any specificimplementation. In examples, the database may comprise a data structurelayer and a storage layer. The storage layer (also referred to asphysical level) is responsible for storing the data in persistentmemory, e.g. on hard drives. The storage layer may use volatile and/orand persistent (i.e., non-volatile) memories for storing the data. Thedata structure layer (also referred to as logical level) is responsiblefor describing how data is stored in the database by using a datastructure. The data structure rules how the data are modeled andorganized for a specific purpose, e.g. storing the data persistently;implementation of data types and operations allowed on data are the mostdatabase-specific at this level.

The method further comprises receiving S20 by the database one or morewrite events. A write event is a request by a system communicativelycoupled with the database to write information in the database, e.g. thesystem is a computer running a CAD application. Writing information inthe database encompasses adding new data in the database and/or removing(that is, deleting) information already stored in the database and/ormodifying already stored data in the database. The database may allowmultiple users working on the database to send their write requests atthe same time, or substantially at the same time. The database may queuemultiple write requests and execute them sequentially. A write event isthus an operation that changes the state of the database after itsexecution by the database, the execution by the database being a commitof a transaction that comprises the write event.

The method further comprises logging S30 each write event received bythe database. Each logged write event thus forms a new state on thedatabase, that is, the commit of a write transaction including writeevents forms a new state of a database. Logging a write event is theoperation of keeping a log in a non-volatile memory. It is to beunderstood that any type of non-volatile memory (also referred to aslong-term persistent storage) may be used. A log file is a file thatstores a chronological record of operations to be carried out by thedatabase, e.g. upon request of system communicatively coupled with thedatabase. Logging a write event thus means storing the write eventreceived by the database at a time tin the log file after the formerlast write event received at a time t-1 in the sequence of write eventsreceived by the database. The log file thus comprises the set of writeevents received by the database. The log file comprises modifications(the write events) to be applied on the stored data in the process of acommitting a write transaction, the write events being inside the writetransaction. A write transaction is the unit of a read/write event of adatabase while keeping its integrity of the data. A transaction itselfconsists a sequence of information to update the database state. Theactual information of a desired database state can be re-constructedfrom a known state and by applying the changes (that is the writeevents) recorded in the log. The write events modify the state of thedatabase as seen by the write transaction.

The method further comprises buffering (S40) pages modified or createdby the one or more write events. As already said, database pages are theinternal basic structure to organize the data in the database files, anda page is a basic unit of I/O operation. A database page is a contiguousblock of the database memory as the smallest unit of data for databasemanagement. The architecture of the database assigns every existing ornew data structures to store their specific information inside pages. Inexamples, a page has a physical identification in the storage hardware(where it exists physically) and a logical identification used to have afixed identifier of this page even though the page evolves over time andhas different physical identifications. In examples, the storage layeris the allocator of a file system which serves as the data structurelayer. Such a mapping between the logical pages and the physical pagesisolates the data structures from the concurrency control model of thestorage layer. A conceptual need is to have a consistent mapping of allthe pages for a transaction running on a given identifier. In someexamples, the identifier may be a timestamp. A timestamp is a sequenceencoded information identifying when a certain event occurred. In otherexamples, the identifier may be a flag denoting the database states(e.g. “version 1.0”). Buffering is to temporarily store the data in aspecific region of a physical memory which is called buffer. Hereinafterthis buffer is called as shared altered state. These two terms might beused equivalently and interchangeably. The shared altered state is astate of altered pages shared between transactions. A shared alter stateis thus born from a transaction and can live without the transaction; itcan be merged with another shared alter state to create a new sharedaltered state which corresponds conceptually to the merge of the twotransactions. Hence, a shared alter state may be linked to a transactionuntil the transaction is either successfully committed or aborted. Incase of abortion of the transaction, the shared altered state may bediscarded. If the first transaction is committed, the shared alteredstate may be available to second transactions, no longer linked to thefirst transaction: it is now considered as all the modified pages sincethe previous patch (meaning that its semantics has changed: it is nomore “the pages modified by a given transaction” but “the modified pagessince the previous patch”).

The method further comprises creating S50 a patch by flushing to adatabase storage the buffered pages if a threshold has been met.Creating a patch means computing a patch. A patch comprises a list ofthe new pages that are modified or created by one or more new writeevents. In examples, a new patch (the last one computed) lists thedifferences between the new patch and a current patch, i.e., the lastpatch obtained before the new patch has been computed. The act offlushing empties the shared altered state and writes its contents tosome non-volatile memory. The threshold for this flushing can be, forexample, the size of the log and/or a size of the buffered pages and/ora time of reconstruction from the log and/or a time that elapsed sincethe last flush was carried out. The time of reconstruction from the logis the estimated time for the re-application of the events logged in theevent log storage to re-construct the identified state.

Such a method exploits a hybrid choice between two alternatives, namelyshadow paging and logging, and improves how to obtain a database thatcombines time-travel properties and long-transaction capabilities(authoring systems), while reducing computing resources and memorygenerated by I/O. This hybrid strategy employs, on one hand, a mappingtable of page versions coupled with a memory write buffer, and on theother hand, an append-only event log storage. In this method, thestorage of the database is divided between an event log storage whichcomprises the log and the data storage which comprises the data pages.Thus, the event log is a sequence of write events representing committed(or going to be committed) operations in course of time; therefore it isa pure sequential structure. The database storage represents an indexedstate. Hence, at each commit of modifications, the data storage does notalways grow, but the log does.

The method is useful for different kind of databases, for example graphdatabase systems as RDF InMemory service. More specifically, it is afoundation strategy to implement three of the four cornerstone ACIDproperties of a database: Atomicity, Isolation and Durability.

Notably, the method provides atomicity for write transactions by anappend-only storage strategy, isolation for both read and writetransactions by a multi-version concurrency control while keeping thedurability I/O cost as low as possible, as well as durability for writetransactions. The method may not wait for the modified or newly createdpages to be flushed to disk before accepting the commit of atransaction, and instead may rely on a log of modifications. Thissignificantly reduces latency and improves the overall performances.Therefore, the method provides transactions that have a low cost in termof creation and commit latency. an append-only strategy where writersnever block readers and readers never block writers, which is wellsuited for a mix workload of read and write transactions. Thesetransactions may be created on any state of the database at a controlledand limited latency cost, taking advantage of this reduced I/O cost,thus enabling a “time travel” access to the history of modificationsmade inside the database for e.g. creative authoring applications.

Furthermore, this strategy is implemented at the storage level of thedatabase and not at the data structure level, which gives theseproperties for free to all data structures of the database. New datastructure can be designed without the need to pay a cost to benefit fromthe properties mentioned in the previous section.

The method is computer-implemented. This means that steps (orsubstantially all the steps) of the method are executed by at least onecomputer, or any system alike. Thus, steps of the method are performedby the computer, possibly fully automatically, or, semi-automatically.In examples, the triggering of at least some of the steps of the methodmay be performed through user-computer interaction. The level ofuser-computer interaction required may depend on the level of automatismforeseen and put in balance with the need to implement user's wishes. Inexamples, this level may be user-defined and/or pre-defined.

FIG. 6 shows an example of the system, wherein the system is a server,e.g., a server hosting a database.

The server of the example comprises a central processing unit (CPU) 1010connected to an internal communication BUS 1000, a random-access memory(RAM) 1070 also connected to the BUS. The server may be further providedwith a graphical processing unit (GPU) 1110 which is associated with avideo random access memory 1100 connected to the BUS. Video RAM 1100 isalso known in the art as frame buffer. A mass storage device controller1020 manages accesses to a mass memory device, such as hard drive 1030.Mass memory devices suitable for tangibly embodying computer programinstructions and data include all forms of nonvolatile memory, includingby way of example semiconductor memory devices, such as EPROM, EEPROM,and flash memory devices; magnetic disks such as internal hard disks andremovable disks; magneto-optical disks; and CD-ROM disks 1040. Any ofthe foregoing may be supplemented by, or incorporated in, speciallydesigned ASICs (application-specific integrated circuits). One or moremass memory devices may be used for implementing the storage layer of adatabase. A network adapter 1050 manages accesses to a network 1060. Theserver may also include a haptic device 1090 such as cursor controldevice, a keyboard or the like. A cursor control device is used in theserver to permit the user to selectively position a cursor at anydesired location on display 1080. In addition, the cursor control deviceallows the user to select various commands, and input control signals.The cursor control device includes a number of signal generation devicesfor input control signals to system. Typically, a cursor control devicemay be a mouse, the button of the mouse being used to generate thesignals. Alternatively or additionally, the server system may comprise asensitive pad, and/or a sensitive screen.

The computer program may comprise instructions executable by a computer,the instructions comprising means for causing the above system toperform the method. The program may be recordable on any data storagemedium, including the memory of the system. The program may for examplebe implemented in digital electronic circuitry, or in computer hardware,firmware, software, or in combinations of them. The program may beimplemented as an apparatus, for example a product tangibly embodied ina machine-readable storage device for execution by a programmableprocessor. Method steps may be performed by a programmable processorexecuting a program of instructions to perform functions of the methodby operating on input data and generating output. The processor may thusbe programmable and coupled to receive data and instructions from, andto transmit data and instructions to, a data storage system, at leastone input device, and at least one output device. The applicationprogram may be implemented in a high-level procedural or object-orientedprogramming language, or in assembly or machine language if desired. Inany case, the language may be a compiled or interpreted language. Theprogram may be a full installation program or an update program.Application of the program on the system results in any case ininstructions for performing the method.

A typical example of computer-implementation of a method is to performthe method with a system adapted for this purpose, e.g., a server. Thesystem may comprise a processor coupled to a memory; the memory havingrecorded thereon a computer program comprising instructions forperforming the method. The memory may also store a database. The memoryis any hardware adapted for such storage, possibly comprising severalphysical distinct parts (e.g., one for the program, and possibly one forthe database).

In an example, the method is employed in the process of generalmanipulation of modeled objects with an authoring application. A modeledobject is any object defined by data stored, e.g., in the database. Byextension, the expression “modeled object” designates the data itself.According to the type of the system, the modeled objects may be definedby different kinds of data. The system may indeed be any combination ofa CAD system, a CAE system, a CAM system, a PDM system and/or a PLMsystem. In those different systems, modeled objects are defined bycorresponding data. One may accordingly speak of CAD object, PLM object,PDM object, CAE object, CAM object, CAD data, PLM data, PDM data, CAMdata, CAE data. However, these systems are not exclusive one of theother, as a modeled object may be defined by data corresponding to anycombination of these systems. A system may thus well be both a CAD andPLM system

For the sake of explanation only, the example of the method employed inCAD systems are now discussed.

By CAD system, it is additionally meant any system adapted at least fordesigning a modeled object on the basis of a graphical representation ofthe modeled object, such as CATIA. In this case, the data defining amodeled object comprise data allowing the representation of the modeledobject. A CAD system may for example provide a representation of CADmodeled objects using edges or lines, in certain cases with faces orsurfaces. Lines, edges, or surfaces may be represented in variousmanners, e.g., non-uniform rational B-splines (NURBS). Specifically, aCAD file contains specifications, from which geometry may be generated,which in turn allows for a representation to be generated.Specifications of a modeled object may be stored in a single CAD file ormultiple ones. The typical size of a file representing a modeled objectin a CAD system is in the range of one Megabyte per part. And a modeledobject may typically be an assembly of thousands of parts.

In the context of CAD, a modeled object may typically be a 3D modeledobject, e.g., representing a product such as a part or an assembly ofparts, or possibly an assembly of products. By “3D modeled object”, itis meant any object which is modeled by data allowing its 3Drepresentation. A 3D representation allows the viewing of the part fromall angles. For example, a 3D modeled object, when 3D represented, maybe handled and turned around any of its axes, or around any axis in thescreen on which the representation is displayed. This notably excludes2D icons, which are not 3D modeled. The display of a 3D representationfacilitates design (i.e., increases the speed at which designersstatistically accomplish their task). This speeds up the manufacturingprocess in the industry, as the design of the products is part of themanufacturing process.

The 3D modeled object may represent the geometry of a product to bemanufactured in the real world subsequent to the completion of itsvirtual design with for instance a CAD software solution or CAD system,such as a (e.g. mechanical) part or assembly of parts (or equivalentlyan assembly of parts, as the assembly of parts may be seen as a partitself from the point of view of the method, or the method may beapplied independently to each part of the assembly), or more generallyany rigid body assembly (e.g. a mobile mechanism). A CAD softwaresolution allows the design of products in various and unlimitedindustrial fields, including: aerospace, architecture, construction,consumer goods, high-tech devices, industrial equipment, transportation,marine, and/or offshore oil/gas production or transportation. The 3Dmodeled object designed by the method may thus represent an industrialproduct which may be any mechanical part, such as a part of aterrestrial vehicle (including e.g. car and light truck equipment,racing cars, motorcycles, truck and motor equipment, trucks and buses,trains), a part of an aerial vehicle (including e.g. airframe equipment,aerospace equipment, propulsion equipment, defense products, airlineequipment, space equipment), a part of a naval vehicle (including e.g.navy equipment, commercial ships, offshore equipment, yachts andworkboats, marine equipment), a general mechanical part (including e.g.industrial manufacturing machinery, heavy mobile machinery or equipment,installed equipment, industrial equipment product, fabricated metalproduct, tire manufacturing product), an electro-mechanical orelectronic part (including e.g. consumer electronics, security and/orcontrol and/or instrumentation products, computing and communicationequipment, semiconductors, medical devices and equipment), a consumergood (including e.g. furniture, home and garden products, leisure goods,fashion products, hard goods retailers' products, soft goods retailers'products), a packaging (including e.g. food and beverage and tobacco,beauty and personal care, household product packaging).

The designing process in CAD is typically a collaborative procedure andrequires several people to work independently or interdependently toeach other. In this matter, it is important for the database of the CADsystem to provide the isolation and integrity of the database state forall users. Such design applications necessitate creative authoring whichrequires investigating different design possibilities by an incrementalmethod and navigating through their history of modifications in a timetravel way. Examples of the method of the present embodiments arediscussed in the context of CAD authoring applications. It is to beunderstood that these examples are not limited to CAD authoringapplications and can apply to any authoring application. More generally,these examples of the present method are not limited to the specificfield of authoring application, that is, these examples of the methodcan apply to any database that stores a database state.

Referring back to FIG. 1, further explanations are provided. A databaseis provided at step S10. For example, this database may include thecollected information of a CAD model design via a creative applicationof an incremental method by a designer or several designers which maywork on the CAD model in parallel. The database may comprise a set ofdata pages as its smallest unit, as previously discussed; It is to beunderstood that any other internal basic structure to organize the datain the database files may be used.

In examples, the database storage stores records into pages and isappend-only. Therefore, the database is immutable; as an example theentire history of all the transactions might be stored in the event logstorage. This is useful for making easier audit and historical queries.

Next, at step S20, one or more write events are received by thedatabase. A write event is a request by a user to write information inthe database to add one or more new data or modify the existing one ormore data already stored on the database. Each write event comprises asequence of information to update the database status. The write eventsmay be sent via an Application Programming Interface (API), or through aRemote Procedure Call (RPC) usually using pipes, sockets, or sharedmemory. For instance, a group of designers working a same productconcomitantly modify 3D parts of an assembly of parts forming a product,and each modification (that is a write event is received) of a partperformed by one or more designers generate the said sequence ofinformation to be applied to update the database.

Next, at step S30, each write event received by the database is logged.Logging can be done using any durable storage mean. In examples, loggingis performed by maintaining one or more files (also referred to as logfile(s)) that store the history of modifications to the stored data inthe process of at least one write event. In other examples, logging maybe performed using a shared log queue or a distributed file system. Thelog stores the history of all the modifications caused by one or moresuccessive write events, even all the write events received by thedatabase. Each logged write event creates a new state on the database,and the log file thus stores information that allow recovering the newstate, or said otherwise, the log stores database transactions caused bythe received write events. It is to be understood that states as commitof transactions are accessible with time travel. Modifications ofnot-yet-committed state are done through write operations creating logevents in memory and new pages in memory. At commit, log events arewritten to disk and pages are either buffered or written to disk.

In examples, logging each write event comprises writing the history ofmodifications that are incurred by the received write event(s) as (underthe form of) the log of event(s) to the event log storage on the memoryfor intermediate transactions which are transactions before flushing tothe database storage (e.g. on a disk). An intermediate transaction (alsoreferred to as unflushed transaction) is a transaction caused by areceived write event and stored on a log, but not yet associated with adurable state of the database. In this situation, the logging acts as acomplete collection of all transaction caused by the received writesevents, and the one or more transactions not yet flushed on the databasestorage of the database are stored as intermediate transactions.

In examples, the event log storage is append-only, i.e., the new logsare always appended to the event log storage instead of replacing itsexisting data. Append-only log storage records data changes that occurby writing each change to the end of the file. In doing this, it ispossible to recover the entire set of received write events by replayingthe append-only log from the beginning to the end. In examples, one ormore past write events (being either flushed to the disk or logged) areperformed again by replaying one or more transactions and/or one or moreintermediate transactions stored on the append-only event log storage.

Next, in step S40, pages modified or created by the received writeevent(s) are buffered. For example, these modified or created pages arethose obtained as a result of the user interactions of the designers ofthe group on the product: their modifications on the product are beingsaved. Buffering means that the pages modified or created by thereceived write event(s) are stored in a memory so that the system willdeal with these pages at a later stage. Hence, the modified versions ofpages of write events are queued in a memory write buffer, and will beflushed at a later stage. Theses modified versions of pages are a set ofpages that are called shared altered state. It is to be understood thatdatabase pages have been chosen for the purpose of illustration only,and that any other database basic unit of I/O operation might be used.

These pages modified or created by the received write event(s) stay inthe buffer memory until a threshold has been met; consequently, when thethreshold is met, the buffer memory is flushed at step S50. Creations ofpatches triggered as a result of the buffer memory flush will bediscussed hereinafter.

In examples, the threshold may be a size of the event log. Hence, whenthe size of the event log exceeds or is equal to the threshold, is thebuffer memory flushed. The event log may be a log file as alreadydiscussed. The size of the event log may comprise the number of receivedwrite events stored thereon and/or the space (e.g. measured in Megabytes(MB), Gigabytes (GB)) taken up by the event log on a storage medium thatstores the event log. For instance, the threshold may be set at 16 MBand the buffered pages are flushed when the size of the event log isequal or greater than 16 MB.

In examples, the threshold may be a size of the buffered pages. Hence,when the size of the buffered pages exceeds or is equal to thethreshold, is the buffer memory flushed. The size of the buffered pagesmay comprise the number of pages stored on the buffer and/or the space(e.g. measured in Megabytes (MB), Gigabytes (GB), . . . ) taken up bythe buffered pages on the buffer. For instance, the threshold may be setat 1 GB and the buffered pages are flushed when the size of the storedbuffered pages equals 1 GB.

In examples, the threshold may comprise a time that elapsed since thelast flush was carried out. Hence, the memory flush is regularly carriedout, e.g. each n seconds or n minutes or n hours or n days or n weeks nmonths and so on.

In examples, the threshold may comprise a time of reconstruction fromthe log. The time of reconstruction is an estimation of the time thatwould be required for replaying part or the whole of the events that arelogged; the time of reconstruction is thus the time for recomputing aset of transactions that occurred or that are logged. In doing this, itis possible to recover the entire set of received write events byreplaying the append-only log from the beginning to the end. Inexamples, one or more past write events (flushed or not on the databasestorage) are performed again by replaying one or more transactionsand/or one or more intermediate transactions stored on the append-onlyevent log storage. The time of the reconstruction from the last flushmay be estimated based on the number of log events in the event logstorage since the last flush was carried out.

Step S50 comprises creating a patch of the pages modified or created bythe writes event(s) that are stored in the buffer once these pages havebeen flushed in the database storage. The created patch can be alsoreferred to as new patch as the system managing the database maycomprise at least one already existing patch previously obtained as theresult of a flush of buffered pages. Each created patch may beidentifiable by assigning an identifier (e.g., a timestamp or anascending integer index) so that it is possible to order all the createdpatches in their order of creation, thus forming a sequence of patches.The flushed patches are therefore in a chronological order of beingflushed by assigning them a respective identifier. The new patch is thusthe latest patch created and stored at the end of the file. The newpatch comprises a list of one or more pages that are modified or createdby the last received write event. The new patch only lists themodifications of pages between the new patch and the penultimate patchobtained as a result of the penultimate flush of the buffered pages.This contributes the improvement of the memory usage and I/O cost.

Thus, the creating of a new patch is performed each time the thresholdhas been met consecutive to receiving by the database of one or morewrite event(s). For each repetition of the creating, a list of the newpages that are modified or created by the new write event(s) received bythe database is created. A sequence of states is therefore obtainedwherein some states have respectively a corresponding patch. Indeed,there is no guarantee that a patch represents a state at least becausethe creation of a patch depends on the flush to the database of thebuffered pages that is triggered by reaching the threshold. Therefore, apatch can represent a state of the database, or a combination of one ormore states of the database, and/or part of one or more states of thedatabase. A state is recursively made of patches. The set of pages Pireconstructed from the set of pages Di of a patch i is recursivelyreconstructed. This can be noted as follows:

P ₀ =D ₀

P _(i) =D _(i)∪(P _(i-1) \D _(i))

For example, and using pseudo-notation, let the first patch be P1, thestate of the database is made of P1 only and it is noted State(P1)=[P1].For a second patch P2, it can be noted State(P2)=[P2]+State(P1).Similarly, a third patch P3 can be notedState(P3)=[P3]+State(P2)=[P1]+[P2]+[P3]. Thus, a patch (e.g., P2) is apart of the database state at state P3. A state of the database is madeof an ordered sequence of patch, e.g. [P1]+[P2]+[P3], and in thesequence, [P1] and [P1]+[P2] also represent database states. ButState(P3) will not see the pages of the patch P1 that were also modifiedin P2: it will see only the latest ones (i.e., the ones from P2).

Thus, the examples of the method may be repeated, that is, the steps S10to S50 are repeated during, for example, the course of a CAD designprocess, and new patches are created and flushed to the database storageeach time the threshold has been met consecutive to receiving by thedatabase further write event(s). Each new patch comprises a list of thenew pages that are modified or created by the new write event(s). Eachnew patch may also further comprise a mapping table and/or a descriptoras it will be discussed later. A sequence of states is thereforeobtained wherein some states have respectively a corresponding patch inthe database storage and their corresponding state is directlyretrievable, as an example via the corresponding mapping table. Databasestates which do not correspond to a patch in the database storage arethe result of transactions before flushing to the database storage,i.e., unflushed transactions. These transactions are made durable bybeing written to the event log storage.

A description of the conceptual model of a database has been previouslydiscussed. In examples, the database comprises a storage layer, whereone may allocate memory, modify it and save the modifications. StepsS30-S50 may be realized by the storage level. The database furthercomprises a data structure layer, where data structures (such as B-Tree)are created by allocating memory in the storage layer and modify thememory areas to create the structures needed. Steps S10-S20 may berealized by the data structure level. FIG. 5 shows an example of therelations between the data structure layer and the storage layer. FIG. 5is discussed hereinbelow.

Referring now to FIG. 3, a schematic example of the creation of a newpatch is now discussed. This example starts with three data pages storedon an append only data storage; these three pages have been alreadyflushed on the database, and as in a traditional shadow pagingarchitecture, when n pages are flushed to disk, a patch of n pages iscreated. Each of these pages has a physical identification of the datain the storage layer where they exist physically, e.g. each page has aphysical address on a storage medium such as a disk drive. In theexample, the database refers to the data pages by their logicalidentification which is not impacted by the evolution of the physicalidentification, e.g. each page has a logical address from the databasepoint of view. These three pages are “referenced” in an already existingpatch as they have been already flushed. To that aim, the patch maycomprise a mapping table. The mapping table should be defined before toestablish a mapping between the said logical and physicalidentifications. It is to be understood that any other technique otherthan using a mapping table might be used to access a file on disk. Thepatch created after the flush of the three pages comprises a mappingtable. The mapping tables may be seen as a theoretical multi-versionindex. They execute the same function as theoretical multi-versionindexes but without actually implementing a full multi-version index soas to improve the performance. As shown in FIG. 3, for the timestamp T1,the mapping table maps the logical addresses (1,2,3) to the physicaladdresses (adr #1, adr #2, adr #3) in the storage, respectively. For thetimestamp T2, pages 1 and 3 are modified. The logical addresses are notchanged and instead the new mapping table points to the old physicaladdress for page 2 in T1 and new physical addresses of pages 2 and 3 inT2. When a transaction is created (or opened) on the database, thismapping table is built or instantiated in memory between the logicalpages and the physical pages. Therefore, the data structure sees onlyits logical pages, without any knowledge of the physical pages and thedata structure sees only its logical pages, without any knowledge of thephysical pages. If a mapping table already exists in memory, the newmapping table is created by duplicating an existing mapping table, e.g.,the mapping table of the previous timestamp and applying the localmappings up to the desired transaction and the database state. If theredoes not exist a mapping table, all the patches are scanned by jumpingback from descriptor to descriptor, e.g., from descriptor of the patchtimestamped T2 to the descriptor of the patch timestamped T1, and so on,to get the latest version of all pages that is being defined by thefirst descriptor chosen to use. This mapping table strategy will reducethe memory cost of single multi-version index and its high contention onlocks. An implementation of the mapping table may be selected forobtaining a table with the fastest association between an integer and aninteger/pointer. In examples, the mapping table may beperformance-efficiently created based on a lockless compare-and-swaparray, as known in the art. In other examples, the mapping table may becreated based on userland read-copy-update (RCU) mechanism ofsynchronization.

In the example of FIG. 3, the patch comprises a list of one or more newpages that are modified or created by the new write event(s), andfurther comprise as well as a descriptor. A patch representing a set ofpages, the patch may be subject to some alignment constraints in orderto be able to take advantage of the mapped memory. For instance, 4kbytes per pages are allocated in the virtual memory of Intel© and Arm©processors; as another example, the manager of virtual memory ofWindows© imposes patches to be aligned by block of 64 kbytes; thereforea patch is a multiple of 64 kb blocks and the descriptor is written atthe end of the last 64 kb block. The descriptor may be added as the lastelement to be written at the end of the memory block containing thepages of the patch to support atomicity: the presence of the descriptorindicates that the pages have been committed successfully saidotherwise, writing this descriptor at the very end provides an easy wayto verify that the entire patch has been registered correctly-.Otherwise, all data found after the previous descriptor are ignored,i.e., discarded. In examples, a descriptor may comprise at least one ofthe following:

-   -   The number of physical pages modified or created by the new        write event(s). Thus it is possible to find the beginning of the        current patch and finding the previous patch and easier        pre-allocation of the memory to resources associated with the        patch.    -   Metadata for checking integrity of the descriptor, thus ensuring        that the descriptor is not corrupted.    -   A timestamp for the write event(s) represented by the patch. The        sequential order of commitments of the patches (that is, their        flush) can be retrieved from the descriptor. This improves the        reconstruction of the database if necessary.

The presence of the descriptor may provide a reliable stop condition forthe algorithm of page mapping. Back to the example of FIG. 3, thepatches comprise a list of one or more new pages that are modified orcreated by the last received write event(s) and a descriptor. Thepatches might further comprise a mapping table as illustrated in FIG. 4,the mapping table comprises the mapping between the said logical andphysical identifications.

The actual information of a desired database state, in particular astate which does not correspond to a patch in the database storage, canbe re-constructed from a known state, i.e., a state with a correspondingpatch in the database storage, in combination to the application of thechanges recorded in the event log files recorded in the event logstorage.

FIG. 2 is a flowchart illustrating an example of accessing andretrieving one of the database states that was stored according to theexamples of the method of FIG. 1 discussed hereinabove. In this example,at least two states of the database have been already flushed from thebuffer and stored on the disk, according to the method. A databasecomprising at least two database states is thus provided at step S210.In step S220, a read event is received by the database to retrieve thedata on an identified state. This identified state may be queried by auser or automatically by a computer. This identified state is a databasestate which already exists on the disk as a result of the flushing tothe buffer or could be a state chronologically between two storedpatches. In either case, the method retrieves a patch in the sequence ofstates from the database storage in step S221. As previously explained,the patch retrieved for building the database state involves theretrieval of preceding patches as a patch is generally notself-sufficient. In the former case, this retrieved patch is thecorresponding patch of database state which has been flushed to the diskas the result of a write event. In the latter case, the method retrievesa list of logged write event that occurred between the retrieved patchand the identified state. In an example, the retrieved patch is a firstpatch before the identified state in the chronological order. In anotherexample, the retrieved patch is the first patch after the identifiedstate in the chronological order. In other example, the retrieved patchis the closest patch to the identified state in the chronological order,i.e., minimizes the length of the list of the logged write eventsoccurred between the retrieved patch and the identified database state.Then, in step S222, the method retrieves the list of the logged writeevents that occurred between the retrieved patch and the identifieddatabase state. These log files keep the history of modifications of thedata pages. In step S223, the identified database is recovered byapplying the list of logged write events to the retrieved patch.

FIG. 5 illustrates an example of the commit sequence according to thepresent method. The transaction manager receives one or more writeevents as the series of command1, command2 stored in an event log. Therole of the transaction manager is to link the data structures with thestorage layer's transaction and orchestrate the commits of the commandsof the event log. The commit starts with (1) the transaction managerthat orders to store each received event to the event log. As a resultof this order, the event is written on the event log that may be anappend-only event log storage, and then the storage layer acknowledges(2) to the transaction manager that the event has been stored. Storingthe received write events on the event log instead of directly storingon the database the modified or created pages greatly reduces the I/Ovolume and therefore decreases potential overloads of the storage layer.Steps (1) and (2) may be potentially impacted by latency; however, thisis not a problem as all the received write events are known and loggedby the database and the received write events can be committed in thedatabase at a later stage.

After the transaction being acknowledged, the transaction manager closesthe transaction; from the transaction manager point of view, this meansthat the received write events are considered by the transaction manageras being treated by the database.

Then, the transaction manager sends (3) instruction to the storage layerto store (4) the modified pages in the buffer that is flushed (5) whenthe threshold is met.

Due to keeping the modified data pages in the memory buffer before beingflushed to the database storage at each commit of modifications, thesize of the event log storage does necessarily grow while the datastorage grows in size only at the commits followed by flushing.

In reference to FIG. 4 and FIG. 5, this example of the commit sequenceaccording to the method can be explained over the two timestamps T1 andT2 showed in FIG. 3. At timestamp T3, as illustrated on FIG. 4, thetransaction manager receives a write event command. The write eventmodifies the data page 2 requested by thread 1. The received write eventis logged in the event log storage by storage layer upon order of thetransaction manager.

FIG. 4 shows an example of a log file. Logging is performed by the knownmethod of art. In examples, a log file, comprises the context of atransaction. The context of a transaction is a pseudo-object thatrepresents its state and it may comprise the responsible thread of thetransaction (thread 1), the beginning timestamp of the transaction (T3)and ending timestamp of the transaction. The ending timestamp refers tothe time of commit of the transaction and is computed when thetransaction is committed. Commit are serialized, that is, thetransactions of modifications follow one another. For example, if Astarts a write transaction and

B opens a write transaction, B will actually start when the writetransaction of A is done (e.g. abort/commit) and the write transactionof B appears as having started after A even if B has started before A isdone.

Back to FIG. 5, after the acknowledgment (2) of the correct log of thereceived event, the transaction manager sends (3) the modified pages tothe buffer. The transaction manager further writes the new data page 2in the shared altered state in the adr #7 of the physical memory.Transaction manager also updates the mapping table corresponding to thenew path with modified page 2. This mapping table is created by firstduplicating the mapping table corresponding to the mapping table of thepatch of the last timestamp in the database storage (T2) which reads as(adr #4, adr #7, adr #5).

Back to FIG. 5, the memory buffer is periodically flushed to disk (5) asa threshold is reached. The threshold for this flushing can be, forexample, the size of the log and/or a size of the buffered pages and/ora time of reconstruction from the log and/or a time that elapsed sincethe last flush was carried out. In this example of the commit sequence,provided that the threshold for the flushing has been met, a new patchis created by flushing the buffered data (adr #7) to the databasestorage. The new patch further comprises the updated mapping table (adr#4, adr #7, adr #5) and the descriptor which includes the respectivetimestamp of the patch (T3).

In reference to FIG. 4 and FIG. 5, one can see that the method supportsatomicity through storing the data pages in append-only storage byproviding a descriptor at the end of each successfully committed patch.Moreover, by providing different mapping tables on the differentversions of the data pages, the isolation for read and writetransactions is supported. This design of the storage layer guaranteesthat either a transaction properly committed, and its modifications arevisible, or its modifications are never visible. Moreover, alltransactions are made durable by being written to the disk; thecorresponding state of some transactions are flushed to the databasestorage as a patch, while the corresponding state of the intermediatetransactions can be re-constructed using the history of modificationsstored in the event log storage in company with a stored patch. This mixof logging and periodic flush of pages to disk supports an optimizedperformance.

The method does not wait for the modified or newly created pages to beflushed to disk before accepting the commit of a transaction, thusdrastically reducing latency. It relies instead on a log ofmodifications to recover the non-stored database states which is moreinteresting in terms of overall performances. The method providestransactions that have a low cost in term of creation and commitlatency.

The append-only strategy where writers never block readers and readersto never block writers since each reader and writer uses its own mappingtable and memory write buffer, provides the optimized performances for amix workload of read and write transactions. These transactions can becreated on any state of the database at a controlled and limited latencycost, taking advantage of this reduced I/O cost. On the other hand, anystate of the database can be accessed, almost equally, by a combinationof the nearest data pages available on disk and a re-apply of the eventlog up to the desired database state. The cost of access is at worstequal to the creation of a mapping table on the memory map data filesplus the cost of replaying the log that generated the number of pagesnecessary to reach the threshold that flushes pages on disk. Thus, themethod provides the capability of time travel access to the history ofmodifications made inside the database for creative authoringapplications.

Furthermore, this strategy is implemented at the storage level of thedatabase and not at the data structure level, which gives theseproperties for free to all data structures of the database. New datastructure can now be designed without the need to pay a cost to benefitfrom the properties presented by this method.

An embodiment has been described. It will be understood that variousmodifications may be made without departing from the spirit and scope ofthe disclosure. Therefore, other implementations are within the scope ofthe following claims.

1. A computer-implemented method for storing a database statecomprising: receiving, at a database, one or more write events; loggingeach write event, each logged write event forming a new state on thedatabase; buffering pages modified or created by the one or more writeevents; and creating a patch by flushing to a database storage thebuffered pages when a threshold has been met.
 2. Thecomputer-implemented method of claim 1, further comprising: repeatingthe creating each time the threshold has been met consecutive toreceiving, at the database, one or more new write events, eachrepetition of the creating including: creating a list of new pages thatare modified or created by the one or more new write events received bythe database, thereby obtaining a sequence of states wherein some stateshave respectively a corresponding patch.
 3. The computer-implementedmethod of claim 2, wherein each created new patch further includes: amapping table comprising a mapping between physical addresses of thebuffered pages and logical addresses of the pages at a data structurelayer of the database.
 4. The computer-implemented method of claim 3,wherein each logged write event has a local mapping table by duplicatingan existing mapping table in a buffer and applying a local mapping up toa desired logged write event.
 5. The computer-implemented method ofclaim 3, wherein the mapping table is based on a locklesscompare-and-swap array.
 6. The computer-implemented method of claim 2,wherein the created patch further includes: a descriptor including atleast one of: a number of physical pages modified or created by the oneor more new write events; metadata for checking integrity of thedescriptor; and a timestamp of new write events.
 7. Thecomputer-implemented method of claim 6, wherein, in a presence of thedescriptor, the logged write event is successfully committed to a memorybuffer, otherwise the logged write event is discarded.
 8. Thecomputer-implemented method of claim 1, wherein the threshold is a sizeof an event log and/or, a size of the buffered pages, and/or a time ofreconstruction from the log, and/or a time that elapsed since a lastflush was carried out.
 9. The computer-implemented method of claim 1,wherein the database storage of data pages is append-only.
 10. Thecomputer-implemented method of claim 1, wherein logging each write eventincludes writing a history of modifications as the log of one or moreevents to a log storage on a disk for intermediate transactions whichare transactions before flushing to the database storage.
 11. Thecomputer-implemented method of claim 10, wherein the log storage isappend-only.
 12. A computer-implemented method for accessing a databasestate comprising: accessing a database having at least two databasestates stored according to a computer-implemented method for storing adatabase state including: receiving, at the database, one or more writeevents, logging each write event, each logged write event thus forming anew state on the database, buffering pages modified or created by theone or more write events, and creating a patch by flushing to a databasestorage the buffered pages when a threshold has been met; receiving, atthe database, a read event on an identified state; retrieving the patchin a sequence of states from the database storage; retrieving a list oflogged write events that occurred between the retrieved patch and theidentified state; and applying the list of logged write events to theretrieved patch, thereby recovering the identified state.
 13. Thecomputer-implemented method of claim 12, wherein the retrieved patch isthe patch that minimizes a length or a size of the list of the loggedwrite events occurred between the retrieved patch and the identifiedstate.
 14. The computer-implemented method of claim 12, wherein thecomputer-implemented method for storing the database state furthercomprises: repeating the creating each time the threshold has been metconsecutive to receiving, by the database, one or more new write events,each repetition of the creating including: creating a list of new pagesthat are modified or created by the one or more new write eventsreceived by the database, obtaining a sequence of states wherein somestates have respectively a corresponding patch.
 15. Thecomputer-implemented method of claim 14, wherein each created new patchfurther includes: a mapping table comprising a mapping between physicaladdresses of the buffered pages and logical addresses of the pages at adata structure layer of the database.
 16. The computer-implementedmethod of claim 15, wherein each logged write event has a local mappingtable by duplicating an existing mapping table in a buffer and applyinga local mapping up to a desired logged write event.
 17. Thecomputer-implemented method of claim 14, wherein the created patchfurther includes a descriptor comprising at least one of: a number ofphysical pages modified or created by the one or more new write events;metadata for checking integrity of the descriptor; and a timestamp ofthe one or more new write events.
 18. A database system comprising: anon-transitory computer readable storage medium having recorded thereona computer program comprising instructions for storing a database statecomprising: receiving, at a database, one or more write events; loggingeach write event, each logged write event thus forming a new state onthe database; buffering pages modified or created by the one or morewrite events; and creating a patch by flushing to a database storage thebuffered pages when a threshold has been met.
 19. The database of claim18, further comprising a processor configured to implement a transactionmanager that links data structures with a transaction of a storage layerand orchestrate commits, wherein: the transaction manager in a datastructure layer sends the event log to the storage layer; persistence ofthe event log on a log-storage is acknowledged by the storage layer; andafter being acknowledged, the transaction manager closes the transactionin the storage layer and sends the modified pages to a memory buffer.20. A non-transitory computer-readable medium having recorded thereon acomputer program comprising instructions for performing a method foraccessing a database state comprising: accessing a database having atleast two database states stored according to a computer-implementedmethod for storing a database state including: receiving, at thedatabase, one or more write events, logging each write event, eachlogged write event thereby forming a new state on the database,buffering pages modified or created by the one or more write events, andcreating a patch by flushing to a database storage the buffered pageswhen a threshold has been met; receiving, at the database, a read eventon an identified state; retrieving a patch in a sequence of states fromthe database storage; retrieving a list of logged write events thatoccurred between the retrieved patch and the identified state; andapplying the list of logged write events to the retrieved patch, therebyrecovering the identified state.